\section{Tracking warnings}

\frame
{
  \frametitle{Tracking warnings}
  Need to be able to identify when a warning of the same issue appears in
	the results of two different analyses \cite{FindBugs06}

  \B
	\item Same analyzer run on two different builds
	\B
		\item Identify which issues are new
		\item Allow audits and comments to be persistent
		(e.g,. ``Not a problem'', or ``Joe should fix this'')
	\E
	\item Different builds of analyzer on the same software artifact
	  \B
	  \item Everytime we change FindBugs, we want to know which 
		reported warnings change
	  \E
  \E
}

\frame
{
  \frametitle{Tracking warnings is important}
  If you want any industrial adoption of static analysis, this is critically important.
  \B
  \item Tools general false positives or don't care issues, don't want to see those
	anew each time analysis is run.
  \item Persistence of audit/triage
  \item Manager feedback
  \item Tracking and improvement of tools
  \item Integration with bug tracker
  \E
}

\frame
{
  \frametitle{Issues when tracking warnings}
  \B
  \item Needs to be insenstive to unimportant changes: line numbers, identation, etc.
  \item Some issues are challenging: package/class renaming, method refactoring, etc.
  \item Want to avoid accidental collisions (e.g., fix one null pointer bug but introduce another)
  \item Generally, practicions would prefer to accidental collisons rather than seeing issues reappear
  \E
}

\frame
{
  \frametitle{FindBugs supports two ways to track warnings}
  \B 
  \item Compare two bug collections, identify matching instances
	(each is matched to at most one instance in the other collection)
	  \B 
	\item This approach does better fuzzy matching, can handle things such as 
		package renaming
		
	  \E 
  \item Compute instance hash for each instance
	  \B 
		\item This approach is more flexible, doesn't assume linear sequence 
			of versions, integrates better with databases and other 
			static analysis tools
	  \E
  \E
}

\frame
{
  \frametitle{Matching bug collections}
\B
\item Use edu.umd.cs.findbugs.workflow.Update
\item Invoke  mergeCollections
\B
\item
	BugCollection origCollection 
\item
	BugCollection newCollection
\item   boolean copyDeadBugs - should issues not present in new collection be excluded?
\item
 boolean incrementalAnalysis - might newCollection contain results for only a subset of what was examined in origCollection
\E
\E

}

\frame
{
  \frametitle{How matching works}
Uses a sequence of matchers
\B
\item A precise matcher
\item A version insensitive matcher: ignores source line annotations and integer percentage annotations
\item A fuzzy matcher: allows error reclassifications (e.g, a different kind of null pointer warning)
\item A fuzzy matcher that allows package renaming
\E
}

\frame
{
  \frametitle{Things that are important}
\B
\item Classes, methods, fields
\item variable names
\item String constants
\E
}


\frame
{
  \frametitle{Adding important stuff to your bug instances}
\B
\item Code being analyzed should be compiled with variable names (and source line numbers)
\item If you write a detector, decorate bug instance with things you except to be invariant, such as variable names
\item Not only will this help the user, but it will be useful in tracking defects across versions
\E
}

\frame
{
  \frametitle{Instance hashes}
\B
\item Call getInstanceHash() on a bugInstance
\item But the string returned is not guaranteed to be unique
\item Call computeBugHashes() on a SortedBugCollection
\item append getInstanceOccurrenceNum() and getInstanceOccurrenceMax()
	to get a key that is unique for this bug collection
\E
}

\frame
{
  \frametitle{Combining bugs to reduce collisions}
\B
\item
If you are getting lots of collisions, consider merging the instances that would collide into a single bug instance that references multiple source statements.
\item This is also helping when auditing defect warnings
\item Use a BugAccumulator to make this easier
\E
}




